Subject: Proposed Update to TRS Architecture

From: [email-masked]
Date: Mon, 3 Oct 94 15:14:10 EDT

Matthew,

I agree that this is a problem in the architecture, and a solution is required.
If, in your example, NNA had merely changed its node type from NN to EN, there
is no problem because when NNA connects to NNB as an EN, NNB will broadcast a
TDU inoping the TG from VRN1 to NNA.  For the general case, however, when NNA
goes away and doesn't come back (or takes awhile before doing so), other NNs
can still be mistakenly building routes through that node if it was connected
to a connection network.

Regarding your proposed solution, the direction you're considering is
definitely worth pursuing, although you don't specifically mention when these
CP-CP session reachability checks are done.  When dealing with large networks
consisting of 100+ NNs, you don't want to be checking the CP-CP session
reachability of NNs very often.  The architecture update you mentioned in
your note (8083) does this check during session initiation only if:
a)  the NN can't find the destination LU in its local directory  AND
b)  the DLU name matches the CP name of an NN entry in the topology database
    (i.e. the OLU wants to talk to an LU on the NN)

It's rare that both of these conditions hold true, so for the
majority of sessions this check is not performed.  When they are true, only the
NN whose name matches is being checked.  Many, probably most, NNs (especially
if they are routers) in the network won't be checked with the 8083 fix.  I
agree that in many cases the tree for this route is already cached.  If there
are no ENs connected to the local NN that talk to the ENs connected to any
remote NNs, however, a tree is probably not already cached that contains a path
between the two NNs.

One way to solve this problem, which reduces the number of times these
CP-CP reachability checks need to be done to the bare minimum, is to add the
following capability to NNs:

Whenever a local TG to an NN goes down, the local NN checks whether a route
using COS CPSVCMG can still be built to that partner NN.  If so, send a TDU
inoping that TG only.  If a route can't be built, send a TDU inoping the TG
and marking the partner NN as inconsistent (odd RSN).  Now all NNs are clued
in simultaneously, as soon as the disconnection happens, not to use the NN
that disconnected from the network, while only one check needs to be done.
This solves the problem with a minimal # of these CP-CP session reachability
checks being done.

This is a topic that is worth pursuing at the APPN reference SIG at our
upcoming AIW.

Comments from Matthew or anyone else in the peanut gallery would be
appreciated.

Thanks for bringing this to everyone's attention Matthew.  Let's work together
to solve it.

Regards,
Tim